In computing systems, instance level access control, also known as instance level authorization, resource level authorization and fine grained control, is used to determine if a given principal, e.g., a user or a computer program, has authorization to perform a given task on a given instance of a resource. For example, instance level access control can be used to determine if a given user has the authority to modify a given organization profile in a computer system.
Access is usually determined either by making a specific call to determine if authorization has been granted or by trying to perform the action and having the authorization system throw an exception if access is not allowed. Either of these approaches works well if considering only a single instance of a resource. The main problem is how to efficiently generate a list of resources to which a user can apply an action.
The obvious solution would be to fetch all such resources from persistent storage and then test each one individually, filtering out those that did not pass the test. However, this is far too inefficient for large sets of resources. Alternative solutions have been proposed and are addressed below.
The most common way to deal with the problem of efficiently listing a set of resources to which a person has access is to hard code the access control policy into the application code, in the form of a query, and have the application simply execute the query. A problem with this approach is that it does not allow for externalization of the authorization decision and requires recoding of the application each time the policy changes.
Instead of using policy-based authorization, a system may use explicit access control lists. An access control list is a list of users and actions attached to each resource. A user can perform an action on a resource only if a pairing including the user and the action appears on the list. To select the set of resources a user can access, the system simply selects all resources where the user and action appear on the list. Access control lists may also include pairings of user groups and actions. In which case, the selected set of resources includes those where the action and groups to which the user belonged appear in the access control list.
The disadvantage of access control lists is that they are hard to maintain, take a significant amount of space to store and do not reflect the policy that was used to assign users and actions to resources. This is particularly a problem in systems where new objects are being generated dynamically and frequently.
This disadvantage still holds for role-based systems that use access control lists. Although the problem is potentially reduced by using roles instead of users in an access control list, since roles are less dynamic, there is still the problem of maintaining the lists. Policy-based approaches alleviate the maintenance problem, but introduce the problem of how to quickly generate the list of resources a user can access.
U.S. Pat. No. 6,237,036 discloses a method for taking a set of policies, expressed as rules, and then applying the set of policies to a set of resources to generate a set of access control lists for a given set of users. Whenever any item of information such as a rule, a resource or a user changes, the set of access control lists needs to be regenerated or recompiled. This approach suffers from the problem that the access control lists can get out of sync with the policies and the current state of the system. Also, this approach does not address the problem of efficiently generating a list of resources on which a given user can perform a given action. While it may be possible to iterate through all resources and check the access control lists, this approach is inefficient.
U.S. Pat. No. 6,014,666 discloses a method which defines roles at development time. Authorization checks are performed in the code based on the roles. At deployment time, users and groups are mapped to roles. This is essentially the Enterprise JavaBeans (EJB) security model, with the disadvantage that there are no deployment descriptors.
This approach effectively hard codes the role-based authorization policies in the code and in that way is equivalent to the typical hard coding approach mentioned above. Also, this approach does not directly address the problem of generating lists of accessible resources for a given user, and is not for a policy-based authorization system.
Thus, there is a need for improved techniques for providing access control or authorization in computing systems.